Security Wine (бывший - DevSecOps Wine)

Jenkins secrets extraction

Возвращаемся к нашему квизу, который вызвал бурные обсуждения в чате. 59% человек посчитало, что схема является безопасной с точки зрения управления секретами. Как итог они оказались неправы. Дело в том, что упомянутый плагин сredentials-binding может позволить разработчикам извлечь секреты даже если секреты используются во внешнем хранилище Vault. Но дело даже не в плагине, а в самой возможности разработчика влиять на конфигурацию сборки, ведь с тем же успехом можно извлечь секреты напрямую из $JENKINS_HOME/credentials.xml и $JENKINS_HOME/secrets воспользовавшись hudson.util.Secret.decrypt или сторонними инструментами.

Так как разработчик имеет доступ к конфигурации сборки и ее запуску в Jenkins, то помимо извлечения секретов может быть поднят reverse shell или вызван DoS всего сборочного конвейера. Все зависит от сетевых доступов и прав на агенте сборки.

Какой же вывод? Как ни странно, то компенсирующей мерой сделать так, чтобы конфигурация джобы тащилась из внешнего Jenkinsfile, который будет расположен в Git, а разработчик мог эту джобу только запустить. Jenkinsfile на стороне Git-репозитория в свою очередь будет защищен принудительным merge approval и другими мерами, которые могут быть реализованы на стороне SCM.

#dev #ops #talks #attack

www.tg-me.com/jp/DevSecOps Wine/com.sec_devops/517

3.9K viewsDenis Yakimov, edited  Aug 6, 2021 at 07:43

Jenkins secrets extraction

Возвращаемся к нашему квизу, который вызвал бурные обсуждения в чате. 59% человек посчитало, что схема является безопасной с точки зрения управления секретами. Как итог они оказались неправы. Дело в том, что упомянутый плагин сredentials-binding может позволить разработчикам извлечь секреты даже если секреты используются во внешнем хранилище Vault. Но дело даже не в плагине, а в самой возможности разработчика влиять на конфигурацию сборки, ведь с тем же успехом можно извлечь секреты напрямую из $JENKINS_HOME/credentials.xml и $JENKINS_HOME/secrets воспользовавшись hudson.util.Secret.decrypt или сторонними инструментами.

Так как разработчик имеет доступ к конфигурации сборки и ее запуску в Jenkins, то помимо извлечения секретов может быть поднят reverse shell или вызван DoS всего сборочного конвейера. Все зависит от сетевых доступов и прав на агенте сборки.

Какой же вывод? Как ни странно, то компенсирующей мерой сделать так, чтобы конфигурация джобы тащилась из внешнего Jenkinsfile, который будет расположен в Git, а разработчик мог эту джобу только запустить. Jenkinsfile на стороне Git-репозитория в свою очередь будет защищен принудительным merge approval и другими мерами, которые могут быть реализованы на стороне SCM.

#dev #ops #talks #attack

BY Security Wine (бывший - DevSecOps Wine)